Validate sprint7 solver input bounds - #80

Motivation

• The sprint7 solvers trusted untrusted stdin sizes and contents, allowing negative or huge n to trigger NegativeArraySizeException/OutOfMemoryError and permitting integer overflow when accumulating point totals.
• The Levenshtein solver buffered unbounded lines and does O(n*m) work with no input-size guard, enabling memory or CPU exhaustion on oversized inputs.

Description

• Added MAX_GAMES and MAX_TOTAL limits and validated points.length and each point before use in EqualSums, and changed the accumulator to a long to avoid overflow when computing the bitmap target (then cast to int).
• Added checks in EqualSums.run() to validate n and per-point values read from stdin to avoid negative sizes or oversized allocations.
• Added MAX_LINE_LENGTH and pre-checks in LevenshteinDistance.solve() and changed FastIn.nextLine() to nextLine(int maxLength) which enforces a maximum line length and caps buffer growth to prevent unbounded buffering.
• Updated CLI usage to call the bounded nextLine(MAX_LINE_LENGTH) for both input lines in LevenshteinDistance.

Testing

• Ran mvn test and the full test suite completed successfully after the changes.
• Compiled the modified classes with javac -d /tmp/ckj_classes src/main/java/algorithms/sprint7/EqualSums.java src/main/java/algorithms/sprint7/LevenshteinDistance.java and exercised them via the CLI to confirm expected behavior for normal inputs.
• Verified unsafe cases produce graceful errors instead of JVM crashes: negative n or overly large n/point totals in EqualSums return an IO/argument error rather than NegativeArraySizeException/OutOfMemoryError, and overly long lines to LevenshteinDistance produce an Input line is too long error instead of unbounded OOM or excessive CPU.
• Performed quick smoke checks that the solvers still return correct results on representative valid inputs (examples executed via java -cp /tmp/ckj_classes algorithms.sprint7.EqualSums and algorithms.sprint7.LevenshteinDistance).

Codex Task